-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azurerm_container_app_environment
- add support for Azure Monitor as a log destination
#26047
base: main
Are you sure you want to change the base?
Conversation
azurerm_container_app_envrionment
- add support for Azure Monitor as a log destinationazurerm_container_app_environment
- add support for Azure Monitor as a log destination
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @oWretch
Thanks for this PR - I've taken a look through and left some comments inline, but I suspect we can infer the value for the logs_destination
field from log_analytics_workspace_id
having a value, so we might be able to default this to using Azure Monitor unless you specify a Log Analytics Workspace ID, to remove the extra field/hard-coded values - WDYT?
Thanks!
"logs_destination": { | ||
Type: pluginsdk.TypeString, | ||
Optional: true, | ||
Computed: true, | ||
ValidateFunc: validation.StringInSlice([]string{"log-analytics", "azure-monitor"}, false), | ||
Description: "The destination for the application logs. Possible values are `log-analytics` or `azure-monitor`.", | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things here:
- Rather than making this Computed, which'd mask any default value for this field - can we default this here until 4.0 (at which point we can make this field required).
- Whilst I can see that the
Description
field is a string value, do you have a canonical source for the casing of the valueslog-analytics
andazure-monitor
- is that what the API is returning/defined somewhere? Typically we source these fromhashicorp/go-azure-sdk
, but since this is a String field we don't have a backing constant for that, so it'd be good to confirm the casing (and file an upstream issue to fix this, once we have that available)
"logs_destination": { | |
Type: pluginsdk.TypeString, | |
Optional: true, | |
Computed: true, | |
ValidateFunc: validation.StringInSlice([]string{"log-analytics", "azure-monitor"}, false), | |
Description: "The destination for the application logs. Possible values are `log-analytics` or `azure-monitor`.", | |
}, | |
// TODO: make this Required in 4.0 | |
"logs_destination": { | |
Type: pluginsdk.TypeString, | |
Optional: true, | |
ValidateFunc: validation.StringInSlice([]string{"log-analytics", "azure-monitor"}, false), | |
Description: "The destination for the application logs. Possible values are `log-analytics` or `azure-monitor`.", | |
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively we could infer the value for this field based on log_analytics_workspace_id
having a value, which is probably better here, since there's only 2 sources?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reference to the strings comes from the REST API documentation, though it is worth noting that the documentation implies that none
is a valid value, when the actually mean that the object is empty. This is more clear in the API error message which doesn't quote none.
Which also means we don't want to make the property required, as it is perfectly valid to not configure the log destinations at all.
if appLogsConfig := props.AppLogsConfiguration; appLogsConfig != nil { | ||
state.LogsDestination = *appLogsConfig.Destination | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if an existing Container App Environment (which doesn't set LogsDestination
) is imported into Terraform/queried via the API - is the Destination
field null/have a default value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on the existing setting. A default creation, without specifying a LAW has the LogsDestination as an empty object in the JSON.
internal/services/containerapps/container_app_environment_resource.go
Outdated
Show resolved
Hide resolved
@tombuildsstuff Thanks for the review. I debated how to expose the Azure Monitor setting. You are correct that we can infer the setting based on A second option I considered was to add a property such as Ultimately I decided to expose the underlying setting to first provide a simple way to extend the configuration if Microsoft add a new method in future, and second to conform to the way these settings appear in the Portal. The third is that there are actually three options - the default is that there is no log configuration, so I wanted to expose that option also. I'm happy to go with the above suggestion (though the property name probably needs some discussion). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests are failing with
------- Stdout: -------
=== RUN TestAccContainerAppEnvironmentCertificate_basicUpdateTags
=== PAUSE TestAccContainerAppEnvironmentCertificate_basicUpdateTags
=== CONT TestAccContainerAppEnvironmentCertificate_basicUpdateTags
testcase.go:113: Step 1/4 error: Error running apply: exit status 1
Error: `log_analytics_workspace_id` can only be set when `logs_destination` is set to `log-analytics`
with azurerm_container_app_environment.test,
on terraform_plugin_test.tf line 39, in resource "azurerm_container_app_environment" "test":
39: resource "azurerm_container_app_environment" "test" {
--- FAIL: TestAccContainerAppEnvironmentCertificate_basicUpdateTags (97.37s)
FAIL
hi, Is there a plan to merge this? |
What is the plan for this PR. This feature would be great to have. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @oWretch - Thanks for this, and apologies it's taken a while to get back to it, we've had some team changes and this one slipped through the cracks.
I've left 2 comments below, once they're addressed I think this will be good to run the CI tests and if they're good, we should be able to get this merged.
Thanks
return fmt.Errorf("`log_analytics_workspace_id` must be set when `logs_destination` is set to `log-analytics`") | ||
} | ||
|
||
if env.LogAnalyticsWorkspaceId != "" && env.LogsDestination != "" && env.LogsDestination != "log-analytics" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is simpler as
if env.LogAnalyticsWorkspaceId != "" && env.LogsDestination != "" && env.LogsDestination != "log-analytics" { | |
if env.LogsDestination != "log-analytics" && env.LogAnalyticsWorkspaceId != "" { |
Hi @oWretch - I hope you don't mind, but we have an internal support request for this, so I'm going to push some changes and fix the merge conflicts to get this in. |
fix crash in read fixup customizeDiff logic add consts to remove magic strings
f02f256
to
6a9693c
Compare
I don't mind at all 🙂 This week has been crazy so I didn't have the time to get back to it - I'm happy to see it progress. |
Hi @oWretch and @jackofallops - I fixed the linting on this to see if we could get this merged, but unfortunately there are test failures that would need to be investigated first:
|
Community Note
Description
Add the
logs_destination
property toazurerm_container_app_environment
to allow specifying Azure Monitor as a log target.Since changing the
log_analytics_workspace_id
no longer requires recreating the environment, I have also removed this from the configuration.PR Checklist
Changes to existing Resource / Data Source
Testing
Change Log
Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.
azurerm_container_app_environment
- add support for Azure Monitor as a log destination [azurerm_container_app_environment
- add support for Azure Monitor as a log destination #26047]This is a (please select all that apply):
Related Issue(s)
Fixes #25426